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REMARKS 

I. STATUS OF THE CLAIMS 

Various claims are amended herein. 
Claims 1-1 1 and 22-40 are currently pending. 

II. REJECTION OF CLAIMS UNDER 35 USC 103 AS BEING UNPATENTABLE OVER 
WALKER IN VIEW OF HOOVER 

The present invention as recited, for example, in claim 1 , relates to a computer- 
implemented decision management process for evaluating a customer of an organization having 
more than one account. The process comprises (a) loading all customer and account data 
required for evaluating the customer and each of the accounts; and (b) evaluating the customer 
and each of the accounts via an iterative function which uses the loaded customer and account 
data. 

As recited, for example, in claim 1, the evaluation determines which strategy of a plurality 
of strategies will be used to evaluate each account via the iterative function based on a type of 
the account, evaluates each account for a same product or service via the iterative function with 
the same strategy, and evaluates accounts for different products or services via the iterative 
function with different strategies. 

Moreover, as recited, for example, in claim 1 , the loaded customer and account data is 
loaded at a time prior to the evaluation and is sufficient to evaluate the customer and each of the 
accounts by the evaluation without loading additional customer or account data. 

As an example, in the specific example in FIG. 10 of the application, an iterative function 
(see "next iteration" in FIG. 10) is used to evaluate the customer and each of the accounts. In 
steps 222 and 224, the type of account is taken into consideration. For example, it is 
determined what kind of product or service the account is for. In FIG. 10, different strategies are 
used to evaluate credit card accounts and mortgage accounts, respectively. Via the iterative 
function in FIG. 10, the process loops back so that each account of the customer is evaluated, 
with accounts for different products or services being evaluated with different strategies. 

Therefore, in the example of FIG. 10, via the use of an iterative function, all the required 
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customer and account data is loaded, prior to doing the evaluation for the various accounts. 
The loaded customer and account data is sufficient to evaluate the customer and each of the 
accounts, without loading additional customer or account data. 

Please note that claim 1 specifically recites that the customer and account data is loaded 
at a time prior to the evaluation. 

Moreover, please note that claim 1 recites that the customer and each of the accounts is 
evaluated via an iterative function which uses the loaded customer and account data, and that 
the loaded customer and account data is sufficient to evaluate the customer and each of the 
accounts without loading additional customer or account data. See for example, page 1 7, line 
19, through page 18, line 6, of the specification. See also FIGS. 9, 10 and 11. 

Claims 26, 28 and 29 include somewhat similar recitations as those described above for 
claim 1. 

Walker relates to processing of applications for products and services offered by a 
financial institution. See, for example, the Abstract, and column 5, lines 66, through column 6, 
line 1 5, of Walker. The overall processing of applications is shown in the flow chart which runs 
from FIGS. 40-51 of Walker. 

However, Walker shows the processing of only a SINGLE application by an applicant. 
The process does NOT show the processing of multiple applications by the same applicant. 

For example, FIGS. 40-51 of Walker show the various processes which are executed to 
determine if a respective application is accepted. Final processing is shown in FIG. 51. 
Referring to FIG. 51 , after a decision on a processed application is made, customer information 
is updated in step 2258. Then, the processing ends in step 2260. 

It is important to note that the final processing in FIG. 51 of Walker does NOT loop back 
to FIG. 40 to begin processing of another application of the same applicant. This is significantly 
different than the present invention, where a plurality of accounts of an applicant are evaluated 
via an iterative function. 

Therefore, Walker does not show the use of an iterative function to evaluate more than 
one account, as in various embodiments of the present invention. 

Moreover, if some type of loop back was considered in Walker, it is unclear where such a 
loop back would return. For example, steps 2002 to 2006 in FIG. 40 of Walker relate to the 
loading of customer data. If the system of Walker would require a loop back to steps 2000 or 
2002, such a loop back would be significantly different than various claimed embodiments of the 
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present invention where all the required customer and account data for evaluating a plurality of 
accounts is loaded, since customer data in Walker would have to be reloaded in the system to 
evaluate another application. This operation in Walker would be contrary to the present 
invention as recited, for example, in claim 1 . Please note that Walker also retrieves data in other 
steps, such as in steps 2092 and 2094 in FIG. 43. 

Therefore, it is respectfully submitted that Walker does not disclose or suggest the use of 
an iterative function to evaluate a plurality of accounts of a customer, or the loading of all 
required customer and account data to evaluate a plurality of accounts of the customer, as in 
various claimed embodiments of the present invention. 

Please note that claim 1 also recites that "said evaluating determines which strategy of a 
plurality of strategies will be used to evaluate each account via the iterative function based on a 
type of the account". For example, in operations 222 and 224 in FIG. 10, different strategies 
are used to evaluate an account based on the type of account. 

More specifically, as recited, for example, in claim 1, and as shown in FIG. 10, an 
iterative function (see "next iteration" in FIG. 10) is used to evaluate the customer and each of 
the accounts. In steps 222 and 224, the type of account is taken into consideration. For 
example, it is determined what kind of product or service the account is for. In FIG. 1 0, different 
strategies are used to evaluate credit card accounts and mortgage accounts, respectively. Via 
the iterative function in FIG. 10, the process loops back so that each account of the customer is 
evaluated, with accounts for different products or services being evaluated with different 
strategies. 

It is respectfully submitted that Walker does not disclose or suggest such features. 

★ * * 

To further distinguish over Walker, claim 1 is amended herein to recite the 
customer and each of the accounts thereby being evaluated in a "single pass." Similar 
amendments are made to the other independent claims. A "single pass" indicates that, in the 
evaluation of a customer, the required customer and account data is retrieved and loaded once, 
prior to doing the customer evaluation. After the data is loaded, customer and account rules can 
be run interactively and interchangeably against the data. See for example, page 17, line 19, 
through page 18, line 6, of the specification. 

As described, for example, on page 17, line 19, through page 18, line 6, of the 
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specification, such use of a single pass is particularly important where a respective customer 
has many accounts. Thus, the process does not have to run multiple times with dependencies 
between previous and subsequent occurrences. 

* * * 

On page 3, lines 4-9 of the outstanding Office Action, the Examiner asserts that: 

"Via on-line real-time integration of the many systems (block 52) involved in the process, 
all of the existing customer's accounts (each of the customer's accounts, some can be of 
the same type) are systematically and automatically reviewed (all customer and account 
data loaded without additional data) during the application session to determine the 
aggregate balance amount, which gives rise to the best price being offered to the existing 
customer 10 (evaluating customer) for the requested credit product." 

The above quote from the Office Action corresponds to the disclosure in column 9, lines 
33-39, of Walker. 

However, it is respectfully submitted that this portion of Walker does not disclose or 
suggest the use of an iterative function in the manner recited, for example, in claim 1 of the 
present application and shown, for example, in FIG. 10 of the present application. 

Instead, the above-described disclosure in Walker relates to various steps in the flow 
charts of FIGS. 40-51 of Walker. For example, the above-described disclosure in Walker refers 
to block 52. Step 2006 in FIG. 40 of Walker specifically includes the notation "AS 
ILLUSTRATED IN FIGURE 1 BLOCK 52". 

However, not all data is loaded in step 2006 of FIG. 40 of Walker. For example, Walker 
continues to load additional required data throughout any evaluation process in Walker. For 
example, Walker also retrieves data in steps 2092 and 2094 in FIG. 43. 

Therefore, it is respectfully submitted that Walker does not load all customer and account 
data required for evaluating the customer and each of the accounts prior to initiating the 
evaluation without loading additional customer or account data. 

Please note that claim 1 is amended herein to further clarify that the data is loaded 
prior to "initiating" the evaluation. Similar amendments are made to independent claims 
26, 28 and 29. 

Moreover, the above-described portion of Walker simply indicates that Walker 
determines the best price to offer an existing customer for a requested credit product This 
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portion of Walker does not disclose or suggest that a decision is produced for each account of 
the customer. 

Please note that independent claim 1 is amended herein to recite a respective 
decision being produced for each of the accounts. Similar amendments are made to 
independent claims 23, 26, 28 and 29. See, for example, decisions D1 through D8 in FIG. 10 of 
the present application. 

* * * 

In item 3 on page 6 of the outstanding Office Action, the Examiner asserts that there is 
very little specification support for the term "strategy" and that the Examiner has given very 
broad meaning to this term. 

Page 17, lines 12-14, of the specification, indicate that a single strategy "is typically 
defined by a decision tree in conjunction with other functions (such as matrices, outbound 
events)." 

The concept of a "strategy" is known, and Walker does show a strategy. 

However, the present application does not simply claim a strategy. Instead, the present 
application relates to the use of an iterative function to evaluate a customer and accounts in a 
single pass, in accordance with all the features recited, for example, in claim 1 . 

For example, as indicated on page 17, lines 12-14, of the specification, according to 
embodiments of the present invention, a single strategy "can simply be defined once and then 
reiterated through for each of the different accounts of the same type. As a result, in a single 
pass, all customer and account data can be analyzed and appropriate action can be taken." 

* * * 

In the Office Action, the Examiner refers to the Maximum Debt Burden Offer of Walker. 

The Maximum Debt Burden Offer is disclosed, for example, in column 7, line 57, through 
column 8, line 24, of Walker. As specifically disclosed in column 8, lines 17-24, of Walker, the 
Maximum Debt Burden Offer refers to: 

a maximum loan or line dollar amount whose associated monthly 
payment, when added to the monthly payment amounts for the 
applicant's existing debts and rent or mortgage payment, divided 
by the customers 1 monthly income, creates a debt burden ratio 
(such as 45%) that is specified in the product parameters. If the 
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maximum debt burden amount is negative or not used because 
amount requested is less than designated parameter (e.g., 
$2,500), the amount assigned to Maximum Debt Burden Offer will 
default to product minimum. 

Therefore, generally, Walker simply uses the total debt payments to determine an 
amount that can be loaned to an applicant. Such debt payments might include, for example, 
credit card debt and mortgage debt. 

However, this disclosure in Walker does not indicate the use of an iterative function to 
evaluate each account of a customer for a same product or service via the same strategy and 
evaluate accounts of the customer for different products or services with different strategies as 
recited, for example, in claim 1. For example, as indicated above, Walker shows the processing 
of only a SINGLE application by an applicant. The process does NOT show the processing of 
multiple applications by the same applicant. 

★ * * 

In the Office Action, the Examiner asserts that Walker shows a series of look-up tables 
which are iteratively used in the process of Walker. Therefore, the Examiner correlates the look- 
up tables of Walker to the iterative function of the claimed invention. 

The look-up tables of Walker are disclosed, for example, in column 9, line 66, through 
column 10, line 13, of Walker. From this disclosure in Walker, it appears that the look-up tables 
are used simply as a relational tool to access stored data, such as in a relational database 
model. Such use of look-up tables is significantly different than the use of an iterative function of 
the claimed invention. More specifically, it is respectfully submitted that the look-up tables of 
Walker do not indicate the use of an iterative function to evaluate each account of a customer 
for a same product or service with the same strategy and evaluate accounts of the customer for 
different products or services with different strategies as recited, for example, in claim 1 . 
Instead, the look-up tables of Walker simply indicate that data can be stored and accessed in a 
relational manner. 

* * * 

Hoover describes an "object-based relational distributed database system and 
associated methods of operation that transforms data stored in a plurality of remote, 
heterogeneous user databases into a homogeneous data model." See, for example, the 
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Abstract of Hoover. 

However, in view of the comments above with respect to Walker, and the amendments 
made herein, it is respectfully submitted that the present invention is patentable over the 
combination of Walker and Hoover. 



In view of the above, it is respectfully submitted that the rejection is overcome. 

III. CONCLUSION 

In view of the above, it is respectfully submitted that the application is in condition for 
allowance, and a Notice of Allowance is earnestly solicited. 

If any further fees are required in connection with the filing of this response, please 
charge such fees to our Deposit Account No. 19-3935. 



Respectfully submitted, 



STAAS & HALSEY LLP 




1201 New York Ave, N.W., Suite 700 
Washington, D.C. 20005 
Telephone: (202)434-1500 
Facsimile: (202)434-1501 
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